Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Treat frustum changes as camera changes in Scene#render #6821

Merged
merged 10 commits into from
Jul 30, 2018

Conversation

lukesanantonio
Copy link
Contributor

Before this change, the user could update the frustum but not the camera by resizing the viewer. The Scene would continue to render even when requestRenderMode was enabled because it recognized the frustum had changed, but would not update the cached camera to mark the change as handled. This commit changes cameraEqual (in Scene.js) to take into account the camera frustum.

Also adds equalsEpsilon methods to the *Frustum types to make this work.

Fixes #6812

@cesium-concierge
Copy link

cesium-concierge commented Jul 19, 2018

Thanks for the pull request @lukesanantonio!

  • ✔️ Signed CLA found.
  • CHANGES.md was not updated.
    • If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.

🌍 🌎 🌏

Luke San Antonio Bialecki added 3 commits July 19, 2018 16:41
Before this change, the user could update the frustum but not the camera
by resizing the viewer. The Scene would continue to render even when
requestRenderMode was enabled because it recognized the frustum had
changed, but would not update the cached camera to mark the change as
handled. This commit changes cameraEqual (in Scene.js) to take into
account the camera frustum.

Fixes CesiumGS#6812
@mramato
Copy link
Contributor

mramato commented Jul 19, 2018

Thanks for tracking this down @lukesanantonio! @ggetz can you review? @bagnell are you okay with adding these methods to Frustum?

Fixes #6812

Mention this explicitly in CHANGES and link to this PR or the original issue. Look at other recent bullets in the markdown for examples

@ggetz ggetz self-requested a review July 20, 2018 18:33
Copy link
Contributor

@ggetz ggetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can confirm this fixes the issue! Thanks @lukesanantonio, just a few comments.

CesiumMath.equalsEpsilon(this.top, other.top, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.bottom, other.bottom, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.near, other.near, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.far, other.far, relativeEpsilon, absoluteEpsilon));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bagnell Does it make sense to use the same epsilon for all these values?

CesiumMath.equalsEpsilon(this.aspectRatio, other.aspectRatio, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.near, other.near, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.far, other.far, relativeEpsilon, absoluteEpsilon) &&
this._offCenterFrustum.equalsEpsilon(other._offCenterFrustum, relativeEpsilon, absoluteEpsilon));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these checks are redundant- After updating, you should be able to just check this._offCenterFrustum.equalsEpsilon(other._offCenterFrustum, relativeEpsilon, absoluteEpsilon));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the *OffCenter* variants don't check fov,width, or aspectRatio. Is that still alright?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I didn't realize you only meant the ones you highlighted. near and far checks are def redundant

* <code>true</code> if they pass an absolute or relative tolerance test,
* <code>false</code> otherwise.
*
* @param {OrthographicFrustum} [other] The right hand side OrthographicFrustum.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be required. In practice, it doesn't really make sense to use this function with the first parameter undefined and the second parameter a value. Same for all of these functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, is there a way to mark this in the docs or should I just remove the defined(other) part of the condition?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just update the docs by removing the brackets, [].

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! I didn't realize those brackets mark them optional. Will fix

CesiumMath.equalsEpsilon(this.aspectRatio, other.aspectRatio, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.near, other.near, relativeEpsilon, absoluteEpsilon) &&
CesiumMath.equalsEpsilon(this.far, other.far, relativeEpsilon, absoluteEpsilon) &&
this._offCenterFrustum.equalsEpsilon(other._offCenterFrustum, relativeEpsilon, absoluteEpsilon));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here as for OrthographicFrustum.js

var cameraChanged = checkForCameraUpdates(this);
var shouldRender = !this.requestRenderMode || this._renderRequested || cameraChanged || this._frustumChanged || this._logDepthBufferDirty || (this.mode === SceneMode.MORPHING);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the only place scene._frustumChanged is used? If so, we can probably remove it entirely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used on Line 1513. It didn't look like cameraChanged (or something like it) could be a drop-in replacement so I didn't change it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's fine to leave.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha

@@ -1488,7 +1488,8 @@ define([
Cartesian3.equalsEpsilon(camera0.direction, camera1.direction, epsilon) &&
Cartesian3.equalsEpsilon(camera0.up, camera1.up, epsilon) &&
Cartesian3.equalsEpsilon(camera0.right, camera1.right, epsilon) &&
Matrix4.equalsEpsilon(camera0.transform, camera1.transform, epsilon);
Matrix4.equalsEpsilon(camera0.transform, camera1.transform, epsilon) &&
camera0.frustum.equalsEpsilon(camera1.frustum, epsilon);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add (or modify) a test to the Scene request render specs to test if this is being accounted for.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm having trouble getting the test to fail on master. I'll try again tomorrow but do you have any tips / ideas?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take a look at the other requestRender tests, if you haven't already.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, the newest commit has a test that failed before and passes with these changes.

@hpinkos
Copy link
Contributor

hpinkos commented Jul 24, 2018

@lukesanantonio we want to try to get this in for the next release, so try to address these comments when you have a minute. Thanks!

@lukesanantonio
Copy link
Contributor Author

Sorry for the delay, made some changes but I still need some help on a few things @ggetz @hpinkos

@lukesanantonio
Copy link
Contributor Author

Okay I think this is all good @ggetz

@ggetz
Copy link
Contributor

ggetz commented Jul 27, 2018

Awesome, thanks @lukesanantonio. Please also merge in master when you get the chance.

@ggetz
Copy link
Contributor

ggetz commented Jul 30, 2018

Looks good, thanks @lukesanantonio !

@ggetz ggetz merged commit 6a39ce5 into CesiumGS:master Jul 30, 2018
@lukesanantonio lukesanantonio deleted the frustum-render-fix branch August 17, 2018 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants